在開發經歷中，不知道有沒有人經歷過開發靠資料夾命名做疊代、版本更新靠覆蓋的神奇經歷。一旦命名出錯或是路徑放錯，可能就要花很長一段時間去還原與修復。為了避免以上這種可怕的情境發生在我們自己的開發過程中，對於開發版本的管理在這邊我會跟大家分享我自己習慣使用的工具-Git。
Git是一種分散式版本控制系統，用於跟蹤和管理軟件代碼的變更。它允許多個開發人員協同工作，同時在不同的分支上進行修改，並有效地追蹤代碼的歷史和變更。
Git的一個主要特點是其分散式的本質。這意味著每個開發人員都可以在自己的本地機器上完整地複製整個代碼庫，而不僅僅是受限的“檢出”複本。這使得開發人員可以在沒有連接到中央服務器的情況下工作，並且在完成工作後再將變更推送到共享的代碼庫中。
Git的工作方式是通過提交（commit）來追蹤代碼的變更。每次提交都包含了代碼的修改以及一個相關的說明，這樣在查看歷史時可以明確知道每次變更的目的。開發人員可以創建不同的分支來進行不同的工作，然後將這些分支合併回主分支以整合變更。
另一個重要的Git特點是分支管理。開發人員可以在不影響主分支的情況下創建新的分支，這使得同時進行多個功能的開發變得更加容易。分支之間的變更可以進行合併，這意味著多人協作時可以平行進行工作，然後將變更整合到一個共同的代碼庫中。
在功能的實作上目前市面上有許多的服務進行Git的管理，Github、GitLab、Azure等線上資料庫管理，考慮到GitLab自身建置的麻煩與Azure的微軟常見的不直觀講解，所以我選擇GitHub來跟當年的自己好好教一下。
首先，我們先安裝git
誠如我之前所說的開發環境將會鎖定Windows的開發環境，所以讓我們點擊這個連結並跳到以下畫面
Git for Windows
p.s Vivaldi是我最喜歡的瀏覽器，內建擋各種廣告的機制，有機會再跟大家好好推薦XD
確認下載完畢後執行下載後的應用程式跳出以下視窗
然後就像我們各種APP一樣無腦下一步，等待安裝完之後會跳出安裝完成的畫面
要如何驗證自己是否安裝成功? 我們可以在我們新創的資料夾點擊右鍵檢視是否有Open Git balabalabala的選項
又或是透過Terminal 下 git version的指令檢視當前git版本
假如壞掉的話你下git應該就報錯了XD
在確認好自己已經安裝完git之後我們將其綁上github的儲存庫中
首先，先創建一個新的github repository
創建成功後，會出現以下畫面
接下來在我們的VSCode Terminal切換至Git Bash的指令介面上
因為我們是有既有專案的，所以接下來讓我們看中間區塊將既有專案上傳至此github儲存庫中
按照github所提供的指令，分別設定git remote路徑、git remote branch之後用最後一個指令將其推上去
然後我們再切回我們github的畫面重新整理，就能得到以下畫面
假如你也一樣跳出這個畫面的話，恭喜你，我們學會了怎麼存檔了XD
接下來的時光中只要我們還記得github的帳號我們的雲端開發紀錄就會一直保留在資料庫中
才沒有好嗎
在確認安裝完Git與github的同步後，有了基礎環境我們來講講我覺得非常重要的git branch / git commit命名與管理
(Vincent Driessen. A successful Git branching model. https://nvie.com/posts/a-successful-git-branching-model/ )
為何要進行git branch的分支管理?
在我們第一次使用git 管理的我們的專案時，可能會很習慣的在一條線(當前分支main or master)進行開發，但隨著專案開發所需功能越來越多，又或者是開發人員越來越多的時候，我們一定會遇到
什麼情境要對主要產品分支進行合併?
不同的開發衝突該先以誰的開發分支為主呢?
假如有緊急狀況需要修復，但遇到開發中的分支時需要進行合併嗎?
所以為了更好的管理我們自己對於產品與專案的開發狀態，git管理策略是非常重要的。已經有之前的大神們整理各式各樣的git branch 管理策略，這些策略主要都能帶給我們以下優點：
並行開發：分支允許多個開發者在同一代碼庫中並行工作，而不會互相干擾。每個開發者可以在自己的分支上獨立開發新功能或修復 bug，而不必等待其他人完成他們的工作。
風險控制：通過在不同的分支上開發新功能，團隊可以控制和限制新代碼對主代碼庫的影響。這有助於減小不穩定性，允許在主分支上維護一個相對穩定的代碼基礎。
版本控制：分支管理有助於跟蹤和維護不同版本的代碼。你可以為每個版本或發布創建一個分支，以便能夠隨時回滾到先前的版本或修復特定版本的 bug。
合併和代碼審查：分支使得合併代碼變得更加容易。開發者可以在其分支上工作，然後請求將其更改合併回主分支。這提供了一個機會進行代碼審查，確保質量和一致性。
實驗和功能開發：開發者可以在自己的分支上嘗試新的想法和實驗性功能，而不會影響到主代碼庫。這有助於創新和快速迭代。
而我這邊選擇Vincent Driessen所撰寫之《A successful Git branching model》的分支策略，主要分為5個大型分支類型:
main / hotfix / release / develop / feature
這五種分支類型中有兩個我認為是主要分支，具象化對比的話就是國道1跟國道3。
主分支(master/main)：
該分支意即已完成功能合併、測試項目、符合商務需求，他不能進行local推送，只能透過hotfix與release進行合併分支進行更新，並標上發佈的版本號，這就是所謂的新產品發佈。
開發分支(develop)：
下次發佈版本的最新狀態。從主要分支分出來。有些開發者也稱開發分支為整合分支，自動化測試所根據的程式碼(source code)即是以此分支上的版本為基準來進行測試。
另外，我自己習慣稱呼hotfix / develop / feature為支援分支(省1或台64快速道路)，而每一個支援分支都有自己的目的。例如：功能分支(feature)只能從開發分支(develop)分離出來，也只能與開發分支(develop)合併。
功能分支 (feature branch)：
功能分支顧名思義就是開發新功能的分支。他主要是從開發(develop)分支分離，他同時必須、也只能合併回開發分支，在分支的命名上我自己會根據工單的有無以及需求開發的功能命名。
只要新功能未開發完成，功能分支就會持續存在直到開發完成並合併回開發分支或直到放棄開發此新功能。
發佈分支 (release branch)：
發佈分支是為了發佈新版本而存在的，換言之，可以說是將程式碼與主分支(master/main)合併前的過渡階段，是發佈新版本之前所必須進行的相關手續。在此分支必須進行一些整合性測試，並進行小 bug 修復及增加一些metadata(例如版本號或是 build 日期等)。
修補分支 (hotfix branch)：
修補分支的誕生，通常是因為出現了一個急需在短時間內修復的 bug，無法等到下一次發佈時才修復，例如與伺服器間的通訊有 bug，需要馬上進行更新修正或是資安問題極需馬上修正。
說完了branch的切分管理之後，我們往在細一點的角度看看commit的命名策略。
跟branch一樣，每個人都用自己的開發風格進行commit命名的話，好了的說管理上會比較不方便，當出現bug要回去尋找的時候會被當初一周前自己的commite弄得滿頭問號。
也因此這邊推薦可以看看Kaylla Wen(2019)所寫的《使用 git commit template 管理 git log》來了解log的命名與Template Sample設定。
另外也可以透過ESLint與Huskey來做git lint的格式控管
這邊有自己所使用的一些Title，可以參考看看。
feat: 新功能， 如名稱一般，涉及新功能的開發都需要用feat: <開發的功能>。
fix: Bug修復，涉及Bug修復都需要用feat: <修復的功能>。
merge: 分支合併，合併分支之後紀錄合併所解之衝突。
docs: 文檔改變，未涉及到功能的開發與修復，例如添加註解或是README.md的更新。
style: 代碼格式改變，較常見於Prettier white space<==>Tab。
refactor: 功能重構，既有功能的重開發，包括且不限於套件版本更新後的新使用用法。
perf: 性能優化，透過ESLint又或是優化評分工具跑分完之後，所進行的變更
test: 增加測試代碼，Jasmin或Jset等測試工具的開發與變更
build: 改變build工具。
ci: 與ci相關的設定，添加CI所需config又或者需要進行之Test。
add: 增加一些跟功能無關的檔案，README之類的。
3rd: 增加第三方，所需套件的install或cdn的注入。
那麼今天的內容告一個段落啦~ 恭喜恭喜又前進了一天XD
接下來我們將會將目光暫時放回Angular上，聊聊我們本次的開發核心主題
本日參考資料
Driessen, V. (2010, January 5). A Successful Git Branching Model. https://nvie.com/posts/a-successful-git-branching-model/
Heidi. (2021, March 6). [學習筆記] 如何撰好的 Git Commit Message. https://medium.com/dev-chill/%E4%BD%BF%E7%94%A8-git-commit-template-%E7%AE%A1%E7%90%86-git-log-cb70f95fda2f
Hung, R. (2022, March 30). [Git Note] - 統一團隊的 Git Commit 格式吧！不要再讓 Commit 亂糟糟. https://rexhung0302.github.io/2022/03/30/20220330/
Huang, W. (2019, May 3). Git Commit Message 這樣寫會更好，替專案引入規範與範例. https://wadehuanglearning.blogspot.com/2019/05/commit-commit-commit-why-what-commit.html
Heidi. (2021, March 6). [學習筆記] 如何撰好的 Git Commit Message. https://heidiliu2020.github.io/git-commit-message/
Will保哥. (2013, October 14). 30天精通Git版本控管. https://ithelp.ithome.com.tw/articles/10137473
Will保哥. (2021, August 27). 設定 Angular 專案使用 Husky 簡化 Git Hooks 設定並用 Prettier 統一風格. https://blog.miniasp.com/post/2021/08/27/Angular-husky-Git-hooks-Prettier-formatter
Will保哥. (2021, August 29). 設定 Angular 專案使用 ESLint 進行更嚴格的程式碼撰寫風格檢查. https://blog.miniasp.com/post/2021/08/29/Angular-ESLint-with-so-much-details
iThome鐵人賽
看影片追技術